Hi @aeneasr,
Could you please explain what problem this PR solves?

This method is useful to get aliases for migrations working!

@sio4 any update?

In fact, I wanted to keep functions private if there is no solid reason from the perspective of the package pop itself since that alias logic is originally for internal purposes, and it will not be easy to change the API once it was exposed. At the same time, I think it could be fine because the function to be exposed by this PR is simple and I think there is not much chance to change its behavior.

One thing I want to fix is the name of the function. Actually, I am not a native speaker so my impression of the function name could be wrong but I don't think the following statement is smooth. (Since it will be exposed as fixed name, I think we need to consider it more carefully.)

switch NormalizeDialectSynonyms(driverName) {
...
}

cd.Dialect = NormalizeDialectSynonyms(dialect)

The function name is a verb but it does nothing, just returns a value. How about something like the below?

switch DialectForSynonym(driverName) {
...
}

cd.Dialect = NormalizedDialect(dialect)

I feel DialectForSynonym() is better (straight) but if you have another idea, I would like to hear your opinion.

DialectForSynonym sounds great :) Could also be CanonicalizeDatabaseType(name string)

DialectForSynonym sounds great :) Could also be CanonicalizeDatabaseType(name string)

Oh, indeed!

But would be better to be CanonicalDatabaseType or CanonicalDialect as a form of "noun" name. To align with the term we used and other function names like DialectSupported, let's name it CanonicalDialect.

Will you update the PR? If your sun is already down, I can do that for you.

Just pushed a rename commit to speed up (you already waited too long, sorry for that! :-)

Thanks for your patience @aeneasr! I merged the PR into the development branch after renaming the function.